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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
REQUEST FOR FILING APPLICATION UNDER 37 CFR 53(b) 
WITHOUT FILING FEE OR EXECUTES INVENTOR'S DECLARATION 



Assistant Commissioner for Patents 
Washington, DC 20231 

Sir: 



Atty. Dkt. 3842-3 

Date: September 6, 2000 
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This is a request for filing a new PATENT APPLICATION under Rule 53(b) entitled: 

SECURITY WITH AUTHENTICATION PROXY 
without a filing fee and/or without an executed inventor's oath/declaration. 

This application is made by the below identified inventor(s). Attached hereto are the following papers: 
An abstract together with 

7 pages of specification and claims including 

6 numbered claims and also attached is/are _ 

8 sheets of accompanying drawings. 

This application is based on the following prior foreign application(s): 

Application No. Country Filing Date 

1 9994334 Norway 6 September 1 999 

respectively, the entire content of which is hereby incorporated by reference in this application, and priority is hereby 

claimed therefrom. 

□ This application is based on the following prior provisional application(s): 
Application No. Filing Date 
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respectively, the entire content of which is hereby incorporated by reference in this application, and priority is hereby 
claimed therefrom. 

Certified copy/ies of foreign applications attached. 

This application is a □ continuation/D division/D continuation-in-part of application Serial No. , filed 
Please amend the specification by inserting before the first line: -This application is a □ continuation/!!] division/ 
□ continuation-in-part of application Serial No. , filed , the entire content of which is hereby incorporated by 
reference in this application. 

Please amend the specification by inserting before the first line: -This is a continuation of PCT application No. 

, filed , the entire content of which is hereby incorporated by reference in this application- 
Please amend the specification by inserting before the first line: -This application claims the benefit of U.S. 
Provisional Application No. , filed , the entire content of which is hereby incorporated by reference in this 
application. - 

Preliminary amendment to claims (attached hereto), to be entered before calculation of the fee. 
Also attached. 
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a. 



Inventor: 



Residence: (city) 



Atle 
(first) 
Aremark 



Post Office Address: Nygaard, Aremark, Norway 



R/ESTAD 
Ml (last) 
(state/country) Norway 



Norwegian 
(citizenship) 



(Zip Code) N-1798 



2. 



Inventor: 



Knut Snorre Bach 
(first) 

Oslo 



Residence: (city) 

Post Office Address: Bygdoy Alle 1 1 7 A, Oslo, Norway 



CORNELIUSSEN 
Ml (last) 

(state/country) Norway 



Norwegian 
(citizenship) 



(Zip Code) N-0273 



NOTE: FOR ADDITIONAL INVENTORS, check box [X] and attach sheet with same information. 

Address all future communications to NIXON & VANDERHYE P.C., 1100 North Glebe Road, 8 th Floor Arlinaton 
Virginia 22201. ' y ' 



1100 North Glebe Road, 8 th Floor 
Arlington, Virginia 22201-4714 
Telephone: (703)816-4000 
Facsimile: (703)816-4100 
HWB:lsh 



NIXON & VANDERHYE P.C. 

By Atty: H. Warren Burnam, Jr., Reg. No. 29,366 



Signature: 'Qjf ($\\ ^ /A, 
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Inventor: Dagfinn AARVAAG Norwegian 

(first) Ml (last) (citizenship) 

Residence: (city) Oslo (state/country) Norway 

Post Office Address: Kampheimveien 19, Oslo, Norway 

(Zip Code) N-0685 

Inventor: 

(first) Ml (last) (citizenship) 

Residence: (city) (state/country) 

Post Office Address: , 

(Zip Code) 



5. Inventor: 

(first) Ml (last) (citizenship) 

Residence: (city) (state/country) 

Post Office Address: , 

(Zip Code) 



- ' IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re Patent Application of 

R^ESTAD et al Atty. Ref.: 3842-3 

Serial No. to be assigned Group: unknown 

Filed: September 6, 2000 Examiner: unknown 
For: Security With Authentication Proxy 

jji J=f> ^ 5|c 

Assistant Commissioner for Patents 
Washington, DC 20231 

Sir: 

PRELIMINARY AMENDMENT 

In order to place the above-identified application in better condition for 
examination, please amend the application as follows: 

IN THE CLAIMS 

Claim 3, line 1, delete "or 2". 
Claim 4, line 1, delete "2 or 3,". 
Claim 6, line 1, delete "or 2". 

REMARKS 

The above amendments are made to place the claims in a more traditional format. 

Respectfully submitted, 
NIXON & VANDERHYE P.C. 

September 6, 2000 By: £MmQcl5hjPC J\ 

H. Warren Bumam, Jr. 
HWB:lsh Reg. No. 29,366 

1 100 North Glebe Road, 8th Floor 
Arlington, VA 22201-4714 
Telephone: (703) 816-4000 
Facsimile: (703)816-4100 
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Field of invention. 
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The present invention relates to the field of audio, video and data communications 
across packet based networks, particularly to authentication of end-users and end-points 
in networks complying with the H.323 specification of the International 
Telecommunications Union. 

The problem areas. 

The ITU-T recommendation H.235 of the International Telecommunications Union 
recommends a standard for security and encryption for multimedia terminals complying 
with the H-Series recommendations (H.323 and other H.235-based) of International 
Telecommunications Union. H.235 is a new feature in version 2 (H.323v2) of the H.323 
recommendation. It adds various security mechanisms like authentication and integrity 
checks to the recommended standard H.323. In version 1 (H.323vl) of the H.323 there 
were no security mechanisms, and the network had to trust that the end-users were who 
they claimed to be. This constitutes a problem when end-users have their own 
confidential profiles in the system including a set of supplementary services. End-user 
authentication is also a pre-requisite when billing the end-user for the H.323 traffic, and 
when building virtual private networks on the H.323 network. 

Even though the use of H.235 looks promising, some major problems remain to be 
solved. One problem is that there is a wide use of H.323 version 1 end-points in use. As 
stated above, only end-points complying with H.323v2 can support H.235. Another 
problem is that very few of the end-points complying with H.323v2 that are on the 
marked today support H.235. Both of these problems need to be solved in an H.323 
network which base its logic on authenticated end-users. 

Another problem area is H.235 itself, since it is very generic and needs a security profile 
to be applied. In a network it is likely that many different security profiles will be in use 
by different end-points. When security profiles are different, conversion of one security 
profile to another security profile cannot be made since the security profiles generally 
will perform different hash function on different data. As a consequence it is not 
practical for the H.323 network components to support all security profiles. 
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An example to illustrate the problem with two clients with different security profiles is 
shown in fig 1 . In this example the gatekeeper (3) needs to support both security 
profiles to be able to authenticate both end-users (1) using the two H.323 clients. 

5 Known Solutions and problems with these. 

One solution to the problems with H.235 is to not base the authentication on H.235 at 
all, and use a proprietary protocol for end-user (1) authentication. This in turn leads to 
two problems: 

10 

1) The end-user (1) has to start two programs, the authentication client, and the H.323 
client when using the H.323 network even though the H.323 client is a version 2 client 
with H.235 support. 

is 2) The H.323 network has to support a new proprietary protocol in addition to H.323. 

Another known solution is to apply the IMTC Security Profile 1 (SP1) proposed by the 
International Multimedia Teleconferencing Consortium. It is however focused on 
message by message authentication and integrity, and has not made a clear distinction 
20 between user authentication and message integrity. 

Objects of the invention 

Accordingly, it is an object of the present invention to provide an arrangement in a 
25 H.323 network that will allow authentication of end-points that comply with H.323vl . 

Another object of the present invention is to provide an arrangement in a H.323 
network, which will allow authentication of end-points that comply with H.323v2 but 
do not support H.235. 

30 

A further object of the present invention is to provide an arrangement in a H.323 
network, which will allow authentication of end-users (1) clients with different security 
profiles. 

35 Brief description of the invention 



3 

The above objects are met in an arrangement provided by the present invention, 
wherein an authentication proxy is provided and a gatekeeper supports a security 
profile used by an authentication proxy . 

5 Description of the drawings: 

Fig 1 shows how the registration procedure is performed according to prior art when 
two end-points that support either H.323vl or H.323v2 without support for H.235 
performs a registration towards a gatekeeper. In this scenario the Gatekeeper has to trust 
10 the end-points to be who they claim to be since no authentication actions are supported. 

Fig. 2 shows an example of a prior art arrangement in which the gatekeeper (3) 
encounters different clients with different security profiles. The registration is following 
the same procedural flow as shown in Figure 1 (but now with H.235). In this 
is arrangement the gatekeeper has to support all the different profiles used by the 

registering end-points. This constitutes a problem because the gatekeeper is a traffical 
node, and supporting several different profiles will slow down its normal operations. 

Fig. 3 shows an example of signal flow of an arrangement according to the invention. 

20 

Fig 4 shows an example of a sequence of signal flow of an arrangement according to the 
invention including the messages sent between the different entities. In this sequence, a 
one stage autentication scheme is shown. 

25 Fig 5 shows an example of a sequence of signal flow of an arrangement according to the 
invention including the messages sent between the different entities. In this sequence, a 
two-stage authentication scheme is shown; this is called challenge/response scheme. 

Fig 6 shows how an applet can be received from the authentication proxy. It is not 
30 necessary that the applet is received from the authentication proxy; it can be received 
from any other entity as long as it sends the http-request with username and password to 
the authentication proxy. Because the security aspects on the client becomes simpler (it 
is not an absolute requirement that the applet is signed) when the applet is received from 
the authentication proxy, this scenario will be used hereinafter. 

35 

Fig 7 shows a block diagram for the authentication proxy with a numbered signalling 
flow for a simple authentication scheme (no challenge/response). If a 
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challenge/response scheme is used, then the signalling flow must be extended between 
point 9 and 10 according to figure 5. 

Fig. 8 shows a schematic representation of an embodiment example of a sequence of 
5 signal flow in an arrangement according to the invention. 

Detailed description of embodiments. 

In the following, by way of example the present invention will be described in more 
10 detail. 

Referring to fig. 7, an example of an embodiment of the present invention is shown. All 
information the authentication proxy needs, will be requested from the end-user (1) 
through standard http communication or any other suitable protocol. 

15 

In the following, only for the purpose of explaining the present invention the protocol 
used will be http. 

The end-user (1) could be presented a simple html form, an applet (that can be signed), 
20 a servlet or likewise for providing his/her user name and password. This is shown in 
step 1 and 2 in figure 7. If an applet is used it should be signed, so that the end-user can 
be sure of the origin of the applet. The applet must be signed if it is received from 
another entity than the authentication proxy. The reason is that most environments that 
execute applets do not allow applets to communicate with other entities than their origin 
25 unless they are signed. 

The hashing described in the H.235 security profile should be done by the applet if an 
applet is used. If the hashing is not performed by the applet (e.g. according to fig 7.), or 
something else than an applet is used, the communication protocol should instead be 

30 SSL, i.e. https instead of http. The reason for adding a secure socket layer for http is that 
this will avoid the username and password to travel unsecured across the network. 
The hashing will then be performed in the authentication proxy, and the username and 
password will be secured all the way to the gatekeeper. In scenarios when end-point 
supports H.235 but with different security profiles (see fig 2) the authentication proxy 

35 can be used for converting between different security profiles (as shown in fig 3). This 
is beneficial because it keeps the complexity of understanding different security profiles 
away from the gatekeeper. 
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Referring to fig. 7, signal flow is explained in the following by way of example. When 
the authentication proxy (2) receives the information from the user over http, https or 
other standard protocols, it generates a standard RAS message such as a H.323v2 GRQ 

5 (gatekeeper Request), which holds the H.235 data. This is sent directly to a gatekeeper 
(3) according to H.323 v2, where the actual authentication is done. The gatekeeper then 
checks the username and password, and sends back a GCF. A GRJ is sent back if the 
username and password does not match. When the authentication proxy receives the 
GCF, it will send an http-response to the client (step 12). If the authentication proxy 

10 receives a GRJ it will inform the end-point of the unsuccessful authentication attempt in 
the http-response. If challenge/response authentication is used, the authentication proxy 
will wait for an RRQ and a retrieval of an RCF before it sends the http response back to 
the user (see fig 7). 

is The H.323 client can now register with the gatekeeper (3) in a normal way by sending 
GRQ and RRQ. The gatekeeper (3) will know when it receives the GRQ and RRQ that 
the user/end-point (1) already is authenticated based on the user name, the Internet 
Protocol (IP)-address or both. 

20 To avoid problems in the gatekeeper (3) when receiving two GRQ f s (one from the proxy 
(2) and one from the end-point (1)), the authentication proxy can answer GRQ's sent 
from end-points (1) complying with H.323vl and end-points (1) complying with 
H.323v2 without H.235 support directly (This is not shown in figure 8). Because the 
gatekeeper (3) will only receive H.323v2 GRQ's when this feature is added, the 

25 gatekeeper (3) can not, based on the GRQ, decide which version of the H.323 the 
various end-points (1) are complying with. The Gatekeeper (3) should instead base it 
decision on the received RRQs or other suitable RAS messages from endpoints. If this 
scenario is used together with challenge/response authentication. The RRQ must also be 
sent to the authentication proxy (see figure 7). Because of the nature of H.323, this 

30 scenario implies that all further RAS signalling has to go through the authentication 
proxy. 

The authentication proxy can be placed anywhere in the network. In some networks 
where a firewall is present between the client and the gatekeeper, it can be wise to place 
35 the authentication proxy in De-Militarised Zone (DMZ). This misses because it is 
sometimes difficult to let an SSL stream pass through a firewall. 
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Patent claims 

1. 

An arrangement for audio, video, and data communications across packet based 
5 networks implementing the H.323 standard recommended by the International 

Telecommunications Union, the arrangement including one ore more gatekeepers (3), 
characterised in 

that end-user (1) authentication is performed by means of an authentication proxy (2). 
10 2. 

An arrangement according to claim ^characterised in 

that a security profile used by an authentication proxy (2) is supported by a gatekeeper 
(3) associated with said authentication proxy (2). 

15 3. 

An arrangement according to claim 1 or 2, characterised in 

that end-user information needed by an authentication proxy (2) is requested from the 

end-user (1) by means of a non-proprietary communications protocol. 

20 4. 

An arrangement according to claim l,2or3 9 characterised in 

that an authentication proxy (2) communicates information to a gatekeeper (2) by means 

of a H.323 version 2 RAS message. 

25 5. 

An arrangement according to claim 3, characterised in 
that a non-proprietary communications protocol is selected form a group of non- 
proprietary protocols comprising http and https. 

30 6. 

An arrangement according to claim 1 or 2, char act eri se d in 

that information for end-user (1) authentication is provided by the end-user (1) by 

means of an html form, an applet or a servlet. 



Abstract 



An arrangement to accomplish authentication of end-users (1) and end-points (1) in a 
packet based network, which includes components that support all or parts of different 
versions of the H.323 recommended standard, be proposed. Authentication is 
accomplished by means of an authentication proxy (2), which will support security 
profiles supported by one or more associated gatekeepers (3). Provision of end-user (1) 
and end-point information for an authentication proxy (2) may be accomplished by 
means of standard non-proprietary communication and protocol such as http or https 
and a simple html form, an applet or a servlet respectively, and for a gatekeeper (3) by 
means of a RAS message such as gatekeeper request (GRQ). 



Abbreviation / Term 


Description 


Hashing 


Performing hashing means to code a text 
or data according to a specific algorithm. 
The hashed text or data can only de 
decoded by entities that knows the original 
hashing function 


Proxy 


By proxy is meant a function that is not 
taking active part (not an originating or 
terminating signalling or media entity) in 
any communication, the proxy is only 
helping out by doing small enhancements 
or other functions. 


Li 1 -m-% f\ f* /IITI 'd" 

XLflllipOlIll 


By endpoint is meant an entity that either 
originates or terminates signalling (H.323) 
and media (RTP/RTCP) 


RTP 


Real Time Protocol as described in RFC 
1889 


RTCP 


Real Time Control Protocol, described in 
RFC 1889 


End-user 


The person that uses the End-point. 


Authentication 


The procedure to check the identity of 
end-users. Unlike a login procedure, which 
is combined with a logout, authentication 
is a one step function 


SSL 


Secure Socket Layer 


RAS 


Registration, Admission and Signalling 


otcuniy p runic 


A security profile defines which data 
should be hashed, and according to which 
function the data should be hashed. 


Applet 


An applet is a program that is transferred 
from a server to an end-user terminal (e.g. 
a computer) and executed at the end-user 
terminal. 


Http 


Hyprt Text Transport Protocol 


Firewall 


An entity that is placed between a Local 
network and the outside network. The 
main object for the firewall is to prevent 
certain types of traffic to pass from the 
outside network to the inside. 
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